Apparatus and Method of Software Implementation Between a Vehicle and Mobile Device

ABSTRACT

A vehicle computer system (VCS) configured to communicate with a mobile device, comprising a wireless transceiver configured to communicate with the mobile device. The VCS also includes a VCS software stack configured to interact with a mobile device software stack and a processor configured to receive a message from the mobile device indicating a version of the mobile device software stack. The processor is also configured to determine if the VCS needs an update to the VCS software stack based at least upon the version of the mobile device software stack, download an update to the VCS software stack from an off-board server, update the VCS to include the updated VCS software stack, and communicate with the mobile device utilizing the updated VCS software stack.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.14/162,861, filed Jan. 24, 2014, the disclosure of which is herebyincorporated in its entirety by reference herein.

TECHNICAL FIELD

The illustrative embodiments generally relate to an apparatus and methodfor software implementation between a vehicle and a mobile device.

BACKGROUND

U.S. Pat. No. 7,516,201 discloses a communication device and a softwarefor operating multimedia applications in one or more communicationnetworks, with a computing manager unit for managing and providingmultimedia applications on the basis of a communication with one or morecommunication devices in the one or more communication networks, wherebythe computing manager unit controls a device discovery manager unit fordetecting the availability of one or more devices and/or one or morecommunication networks, a service discovery manager unit for providingavailable services from and/or for said one or more communicationnetworks, and a virtual device manager unit providing a graphical userinterface for controlling devices and/or services of the one or morecommunication networks.

WO 2013/039763 discloses systems, software and methods for using amobile phone in conjunction with a head unit of a vehicle. The userinterface of a user application program executing on the mobile phone isextended to utilize a generic display screen of the head unit, so thatcustom or per application development of head unit software can beavoided. Preferably, a handset application proxy (HAP) softwareapplication is installed and executable in the mobile phone; and a headunit proxy (HUP) software component is executable on the head unit. TheHAP and the HUP communicate messages between the head unit and themobile phone. Preferably, the HAP includes a scripting languagecomponent associated with the user application, and having a templatemessage translator component.

SUMMARY

A first illustrative embodiment includes a vehicle computer system (VCS)configured to communicate with a mobile device, comprising a wirelesstransceiver configured to communicate with the mobile device. The VCSalso includes a VCS software stack configured to interact with a mobiledevice software stack and a processor configured to receive a messagefrom the mobile device indicating a version of the mobile devicesoftware stack. The processor is also configured to determine if the VCSneeds an update to the VCS software stack based at least upon theversion of the mobile device software stack, download an update to theVCS software stack from an off-board server, update the VCS to includethe updated VCS software stack, and communicate with the mobile deviceutilizing the updated VCS software stack.

A second illustrative embodiment includes a vehicle computer system(VCS) configured to communicate with one or more mobile devices,comprising a wireless transceiver configured to communicate with amobile device. The VCS also includes a VCS Bluetooth profile configuredto interact with a mobile device Bluetooth profile and a processorconfigured to receive a message from the mobile device indicating aversion of the Bluetooth profile. The processor is further configured todetermine if the VCS needs an update to the VCS Bluetooth profile basedat least upon the version of the mobile device Bluetooth profile,determine if sufficient memory space is available to download andinstall the update to the VCS Bluetooth profile, download a softwareupdate to the VCS Bluetooth profile from an off-board server, thesoftware update including additional features specific to the mobiledevice, update the VCS to include the software update, and communicatewith the mobile device utilizing the updated VCS Bluetooth profile.

A third illustrative embodiment includes a method of a vehicle computersystem (VCS) communicating with a mobile device (MD), comprisingreceiving a message from the MD indicating a version of the MD softwarestack, determining if the VCS software stack needs an update based atleast upon the version of the MD software stack, downloading andinstalling an update to the VCS software stack from an off-board server,and communicating with the MD utilizing the updated VCS software stack.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example block topology for a vehicle basedcomputing system (VCS) for a vehicle.

FIG. 2 illustrates an example flow chart of the vehicle based computingsystem, server, and mobile device interacting with one another during asoftware update.

FIG. 3 illustrates an example flow chart of the vehicle based computingsystem, server, and mobile device interacting with one another.

DETAILED DESCRIPTION

As required, detailed embodiments of the present invention are disclosedherein; however, it is to be understood that the disclosed embodimentsare merely exemplary of the invention that may be embodied in variousand alternative forms. The figures are not necessarily to scale; somefeatures may be exaggerated or minimized to show details of particularcomponents. Therefore, specific structural and functional detailsdisclosed herein are not to be interpreted as limiting, but merely as arepresentative basis for teaching one skilled in the art to variouslyemploy the present invention.

FIG. 1 illustrates an example block topology for a vehicle basedcomputing system 1 (VCS) for a vehicle 31. An example of such avehicle-based computing system 1 is the SYNC system manufactured by THEFORD MOTOR COMPANY. A vehicle enabled with a vehicle-based computingsystem may contain a visual front end interface 4 located in thevehicle. The user may also be able to interact with the interface if itis provided, for example, with a touch sensitive screen. In anotherillustrative embodiment, the interaction occurs through, button presses,spoken dialog system with automatic speech recognition and speechsynthesis.

In the illustrative embodiment 1 shown in FIG. 1, a processor 3 controlsat least some portion of the operation of the vehicle-based computingsystem. Provided within the vehicle, the processor allows onboardprocessing of commands and routines. Further, the processor is connectedto both non-persistent 5 and persistent storage 7. In this illustrativeembodiment, the non-persistent storage is random access memory (RAM) andthe persistent storage is a hard disk drive (HDD) or flash memory. Ingeneral, persistent (non-transitory) memory can include all forms ofmemory that maintain data when a computer or other device is powereddown. These include, but are not limited to, HDDs, CDs, DVDs, magnetictapes, solid state drives, portable USB drives and any other suitableform of persistent memory.

The processor is also provided with a number of different inputsallowing the user to interface with the processor. In this illustrativeembodiment, a microphone 29, an auxiliary input 25 (for input 33), a USBinput 23, a GPS input 24, screen 4, which may be a touchscreen display,and a BLUETOOTH input 15 are all provided. An input selector 51 is alsoprovided, to allow a user to swap between various inputs. Input to boththe microphone and the auxiliary connector is converted from analog todigital by a converter 27 before being passed to the processor. Althoughnot shown, numerous of the vehicle components and auxiliary componentsin communication with the VCS may use a vehicle network (such as, butnot limited to, a CAN bus) to pass data to and from the VCS (orcomponents thereof).

Outputs to the system can include, but are not limited to, a visualdisplay 4 and a speaker 13 or stereo system output. The speaker isconnected to an amplifier 11 and receives its signal from the processor3 through a digital-to-analog converter 9. Output can also be made to aremote BLUETOOTH device such as PND 54 or a USB device such as vehiclenavigation device 60 along the bi-directional data streams shown at 19and 21 respectively.

In one illustrative embodiment, the system 1 uses the BLUETOOTHtransceiver 15 to communicate 17 with a user's nomadic device 53 (e.g.,cell phone, smart phone, PDA, or any other device having wireless remotenetwork connectivity). The nomadic device can then be used tocommunicate 59 with a network 61 outside the vehicle 31 through, forexample, communication 55 with a cellular tower 57. In some embodiments,tower 57 may be a WiFi access point.

Exemplary communication between the nomadic device and the BLUETOOTHtransceiver is represented by signal 14.

Pairing a nomadic device 53 and the BLUETOOTH transceiver 15 can beinstructed through a button 52 or similar input. Accordingly, the CPU isinstructed that the onboard BLUETOOTH transceiver will be paired with aBLUETOOTH transceiver in a nomadic device.

Data may be communicated between CPU 3 and network 61 utilizing, forexample, a data-plan, data over voice, or DTMF tones associated withnomadic device 53. Alternatively, it may be desirable to include anonboard modem 63 having antenna 18 in order to communicate 16 databetween CPU 3 and network 61 over the voice band. The nomadic device 53can then be used to communicate 59 with a network 61 outside the vehicle31 through, for example, communication 55 with a cellular tower 57. Insome embodiments, the modem 63 may establish communication 20 with thetower 57 for communicating with network 61. As a non-limiting example,modem 63 may be a USB cellular modem and communication 20 may becellular communication.

In one illustrative embodiment, the processor is provided with anoperating system including an API to communicate with modem applicationsoftware. The modem application software may access an embedded moduleor firmware on the BLUETOOTH transceiver to complete wirelesscommunication with a remote BLUETOOTH transceiver (such as that found ina nomadic device). Bluetooth is a subset of the IEEE 802 PAN (personalarea network) protocols. IEEE 802 LAN (local area network) protocolsinclude WiFi and have considerable cross-functionality with IEEE 802PAN. Both are suitable for wireless communication within a vehicle.Another communication means that can be used in this realm is free-spaceoptical communication (such as IrDA) and non-standardized consumer IRprotocols.

In another embodiment, nomadic device 53 includes a modem for voice bandor broadband data communication. In the data-over-voice embodiment, atechnique known as frequency division multiplexing may be implementedwhen the owner of the nomadic device can talk over the device while datais being transferred. At other times, when the owner is not using thedevice, the data transfer can use the whole bandwidth (300 Hz to 3.4 kHzin one example). While frequency division multiplexing may be common foranalog cellular communication between the vehicle and the internet, andis still used, it has been largely replaced by hybrids of Code DomainMultiple Access (CDMA), Time Domain Multiple Access (TDMA), Space-DomainMultiple Access (SDMA) for digital cellular communication. These are allITU IMT-2000 (3G) compliant standards and offer data rates up to 2 mbsfor stationary or walking users and 385 kbs for users in a movingvehicle. 3G standards are now being replaced by IMT-Advanced (4G) whichoffers 100 mbs for users in a vehicle and 1 gbs for stationary users. Ifthe user has a data-plan associated with the nomadic device, it ispossible that the data-plan allows for broad-band transmission and thesystem could use a much wider bandwidth (speeding up data transfer). Instill another embodiment, nomadic device 53 is replaced with a cellularcommunication device (not shown) that is installed to vehicle 31. In yetanother embodiment, the ND 53 may be a wireless local area network (LAN)device capable of communication over, for example (and withoutlimitation), an 802.11g network (i.e., WiFi) or a WiMax network.

In one embodiment, incoming data can be passed through the nomadicdevice via a data-over-voice or data-plan, through the onboard BLUETOOTHtransceiver and into the vehicle's internal processor 3. In the case ofcertain temporary data, for example, the data can be stored on the HDDor other storage media 7 until such time as the data is no longerneeded.

Additional sources that may interface with the vehicle include apersonal navigation device 54, having, for example, a USB connection 56and/or an antenna 58, a vehicle navigation device 60 having a USB 62 orother connection, an onboard GPS device 24, or remote navigation system(not shown) having connectivity to network 61. USB is one of a class ofserial networking protocols. IEEE 1394 (FireWire™ (Apple), i.LINK™(Sony), and Lynx™ (Texas Instruments)), EIA (Electronics IndustryAssociation) serial protocols, IEEE 1284 (Centronics Port), S/PDIF(Sony/Philips Digital Interconnect Format) and USB-IF (USB ImplementersForum) form the backbone of the device-device serial standards. Most ofthe protocols can be implemented for either electrical or opticalcommunication.

Further, the CPU could be in communication with a variety of otherauxiliary devices 65. These devices can be connected through a wireless67 or wired 69 connection. Auxiliary device 65 may include, but are notlimited to, personal media players, wireless health devices, portablecomputers, and the like.

Also, or alternatively, the CPU could be connected to a vehicle basedwireless router 73, using for example a WiFi (IEEE 803.11) 71transceiver. This could allow the CPU to connect to remote networks inrange of the local router 73.

In addition to having exemplary processes executed by a vehiclecomputing system located in a vehicle, in certain embodiments, theexemplary processes may be executed by a computing system incommunication with a vehicle computing system. Such a system mayinclude, but is not limited to, a wireless device (e.g., and withoutlimitation, a mobile phone) or a remote computing system (e.g., andwithout limitation, a server) connected through the wireless device.Collectively, such systems may be referred to as vehicle associatedcomputing systems (VACS). In certain embodiments particular componentsof the VACS may perform particular portions of a process depending onthe particular implementation of the system. By way of example and notlimitation, if a process has a step of sending or receiving informationwith a paired wireless device, then it is likely that the wirelessdevice is not performing the process, since the wireless device wouldnot “send and receive” information with itself. One of ordinary skill inthe art will understand when it is inappropriate to apply a particularVACS to a given solution. In all solutions, it is contemplated that atleast the vehicle computing system (VCS) located within the vehicleitself is capable of performing the exemplary processes.

FIG. 2 illustrates an example flow chart of the vehicle based computingsystem, server, and mobile device interacting with one another. Althoughthis figure illustrates the vehicle or vehicle computer system VCS 203communicating with the server 201, the mobile phone or audio gateway 205may also communicate with the server 201. The vehicle 203 may beequipped with a VCS that includes a wired or wireless transceiver tocommunicate with the mobile phone 205.

The VCS 203 may be listening for an audio gateway device or mobile phone207 to begin the pairing process. In other embodiments, the VCS may alsoseek discovery of a mobile phone that is listening to hear from devices.Upon receiving a pairing request from a device, the VCS and mobile phonemay begin the pairing process 209. The pairing process may be unique foreach specific operating system of the mobile phone 209. For example,Android, iOS, RIM, and Windows may each have a unique pairing process tocommunicate with devices. Thus, a software update on the VCS or mobilephone may increase interoperability between the two devices.Additionally, the VCS may require a software update to increaseinteroperability between the devices.

During the pairing process, the mobile phone may request the VCS toindicate the software version of a software stack that is running on theVCS. The mobile device may send a message to the VCS to indicate thatthe software running on the VCS (e.g. the Bluetooth software stack) isold. The software stack may refer to software that is an implementationof the Bluetooth protocol stack. The stack may be used forgeneral-purpose implementations for emphasis on feature-richness andflexibility or embedded system implementations intend for use in deviceswhere resources are limited and demands are lower, such as Bluetoothperipheral devices. The Bluetooth software stack may facilitatecommunication between the HMI layer and the specific Bluetooth profiles(e.g. HFP, A2DP, PBAP, etc.). The software stack may be located at theHost Controller Interface (HCI) layer for Bluetooth implementation.

The VCS or mobile phone may be able to determine whether the softwareversion is up to date for the software stack. For example, the mobilephone may tell the version of the Android respondent stack which maywork the best with the VCS. In alternative, the mobile device or audiogateway device may send data or information representing the version ofsoftware that the mobile device runs. Additionally, the mobile devicemay send a message indicating other information related to the softwarerunning on the mobile device. For example, the message may include theversion number, operating system, phone manufacturer, Bluetooth profileversion information, etc.

Upon determining that the VCS needs new software, the VCS may indicateto the mobile phone to download new software 211 or the VCS may downloadthe software utilizing an embedded cellular transceiver to communicatewith the server 201. The VCS may download the update or new softwarestack onto the VCS or onto the mobile phone. In some scenarios, the VCSmay not have the required memory or space to download the stack. The VCSmay check to determine if sufficient memory is present. The VCS mayreceive data from the mobile phone or off-board server indicating howmuch memory is required for the download and installation.

If insufficient memory is present the system may notify the user with anaudio or visual warning utilizing the VCS to indicate that memory needsto be present in order for the update to occur. Additionally, the VCSmay also request that the user utilize additional flash drives, externalstorage device, or mobile phone to be utilized to save the update.

If the VCS or mobile phone detects an error occurring during thedownload cycle, the VCS may output an error message on the display tonotify the user of the error. The system may automatically try todownload the update stack again. Additionally, if the error occurs onmultiple occasions, the VCS may attempt to install a different softwarestack update than originally anticipated. For example, the VCS may runversion 1.0 of the software stack or profile. The mobile device mayrequest an update to version 3.0 for the VCS. If the VCS is unable todownload version 3.0, the VCS may update an intermediary version, suchas 2.9 or 2.8 instead.

Upon downloading the update, the system may execute an executable fileor run an application to update the software stack. Additionally, thesystem may install various plugins when running the software update. Thesoftware update may initialize a callback to the HMI that is optimizedto operate with the mobile phone. The mobile device may also startstreaming an executable at the Bluetooth chipset level if the phonedownloads the update. The system may then begin to pair the mobiledevice with the VCS according to the process in the specification.

An additional embodiment may include similar configuration, however, itmay determine that an update or additional Bluetooth profile needs to bedownloaded and installed to the VCS and/or the mobile device. Thus, theVCS may determine that a new version of the Bluetooth profile must bedownloaded to the mobile device or VCS. Thus, the VCS may implement aconfiguration similar to the previous embodiments as directed to updatethe Bluetooth profiles of the VCS or mobile device. The embodiments mayinclude a version that updates the software stack, Bluetooth profile, orboth the software stack and Bluetooth profile.

FIG. 3 is an example of the flow chart of the vehicle based computingsystem, server, and mobile device interacting with one another. The VCSmay include a human machine interface (HMI) 301 to allow a user tocontrol various aspects of the system. The HMI may include both a manualinput interface or a voice interface. The VCS 303 and HMI 301 mayinteract with one another. The VCS 303 may include a wireless or wiredtransceiver, such as a USB port or Bluetooth transceiver, to interactwith a mobile device or audio gateway device 305.

The mobile device may request or indicate to the VCS that it needs toutilize the VCS or HMI. For example, the mobile device may receive atext message and send an SMS notification 307 to the vehicle computersystem via Bluetooth. Other requests may include a phone callnotification, request to update a phone book (e.g. via PBAP), request tostream audio files, send audio content, etc. The vehicle computer systemmay notify the HMI layer to call the API which relates to thenotification 309, such as the HMI_SMS_Notify interface. The commandsutilized to communicate between the HMI 301 and the VCS 303 may be afixed message set in certain embodiments. The API will allow the HMI tointeract with the mobile device to display certain information. Eachprofile may have a specific function to call based on the scenario ofthe mobile phone. For example, a phone call may utilize a certainfunction, a text message may utilize another function, audio streamingmay utilize another, etc. Each function may utilize a predefined messageset to interact with the device.

The HMI will update 311 to present the information to the user via theinterface. The interface may be the display or a voice interface. Inaddition, the HMI or VCS may send a message to the mobile device viaBluetooth. The message may contain instructions or commands for themobile device to perform a function, such as dial a number. The commandfrom the HMI-side may be translated to allow the mobile device toperform the operation. For example, the “API Dial_Number” command 313 ofthe HMI may be converted to the “ATD Number” command for the mobilephone 315.

Upon receiving different messages or requests from the HMI, the mobiledevice may respond to those messages 317. For example, after dialing thephone, the mobile device may send a “Callback Call Status” request tothe HMI 319. Again, the VCS may utilize an API or the Bluetooth stack totranslate the message from the mobile device to the message from theinterface.

In another embodiment, the VCS may include a pre-defined HMI that willcommunicate with the mobile device. The mobile device may download a newsoftware stack from an off-board server upon connecting with the VCS.The VCS may download the new software stack and run a software update toinstall the new software stack. A new software stack may be installed oneither the phone or the mobile device. The VCS HMI may interface withthe new software stack to increase interoperability between the mobiledevice and the VCS.

Additionally, the VCS may confirm the message set that is used tofacilitate interaction between the HMI, Bluetooth software stack, andthe mobile phone. The mobile device may confirm the set of messages usedto facilitate communication by sending pre-defined messages to theserver/manufacturer. Thus, the mobile device may utilize the most recentsoftware to facilitate communication. Additionally, the VCS may also beable to send the pre-defined message set, or another message to a serverwith an identification of the mobile device manufacturer or software.Upon the server determining the software stack to use for interaction,the VCS may download a software stack to update.

Additionally, the mobile device may request unique functionality to beimplemented for the HMI of the VCS. The mobile device may request theVCS to download additional software functionality unique for the mobiledevice or manufacturer. For example, the mobile device manufacturer mayrequest unique functionality of the VCS to differentiate theuser-experience from other systems. Thus, the mobile device may requestthe VCS to download an additional software stack or message set toimplement specifically for that specific mobile device.

While exemplary embodiments are described above, it is not intended thatthese embodiments describe all possible forms of the invention. Rather,the words used in the specification are words of description rather thanlimitation, and it is understood that various changes may be madewithout departing from the spirit and scope of the invention.Additionally, the features of various implementing embodiments may becombined to form further embodiments of the invention.

1-20. (canceled)
 21. A vehicle computer system (VCS) configured tocommunicate with a mobile device, comprising: a processor configured to:1.) receive a message from a wireless transceiver in communication witha mobile device, wherein the message indicates a version of the mobiledevice software stack; 2.) determine if the VCS needs an update to a VCSsoftware stack located in memory of the VCS and configured to interactwith the mobile device; 3.) download an update to the VCS software stackfrom an off-board server; 4.) update the VCS to include the updated VCSsoftware stack.
 22. The vehicle computer system configured tocommunicate with a mobile device of claim 21, wherein the determinationis based upon the version of the mobile device software stack.
 23. Thevehicle computer system configured to communicate with a mobile deviceof claim 21, the processor further configured detect an error during adownload cycle and output an error message on a display of the VCS. 24.The vehicle computer system configured to communicate with a mobiledevice of claim 21, wherein the processor is further configured todownload an update to the VCS software stack from an off-board serverutilizing the mobile device.
 25. The vehicle computer system configuredto communicate with a mobile device of claim 21, wherein the processoris further configured to receive a request from the mobile devicedownload an additional VCS software stack including a unique humanmachine interface.
 26. The vehicle computer system configured tocommunicate with a mobile device of claim 25, wherein the processor isfurther configured to output the unique human machine interface upondownloading the additional VCS software stack.
 27. The vehicle computersystem configured to communicate with a mobile device of claim 21,wherein the processor is further configured to determine if sufficientmemory space is available to download the update to the VCS softwarestack.
 28. The vehicle computer system configured to communicate with amobile device of claim 21, wherein the processor is further configuredto determine if sufficient memory space is available to install theupdate to the VCS software stack.
 29. The vehicle computer systemconfigured to communicate with a mobile device of claim 21, wherein theprocessor is further configured to determine if sufficient memory spaceis available to download and install the update to the VCS softwarestack.
 30. The vehicle computer system configured to communicate with amobile device of claim 21, wherein the message includes informationregarding a manufacturer of the mobile device or information regardingan operating system of the mobile device.
 31. A vehicle computer system(VCS) configured to communicate ae mobile device, comprising: a wirelesstransceiver configured to communicate with the mobile device located; aVCS software profile configured to interact with a mobile devicesoftware profile; a processor configured to: 1.) receive a message fromthe mobile device located in the vehicle indicating a version of the VCSsoftware profile; 2.) determine if the VCS needs an update to the VCSsoftware profile based at least upon the version of the mobile devicesoftware profile; 3.) determine if sufficient memory space is availableto download and install the update to the VCS software profile. 4.)download a software update to the VCS software profile from an off-boardserver, the software update including additional features specific tothe mobile device located in the vehicle; 4.) update the VCS to includethe software update; 5.) communicate with the mobile device utilizingthe updated VCS software profile.
 32. The vehicle computer systemconfigured to communicate with a mobile device of claim 31, wherein theprocessor is further configured detect an error during a download cycleand output an error message on a display of the VCS.
 33. The vehiclecomputer system configured to communicate with a mobile device of claim31, wherein the processor is further configured to output a notificationto insert an external memory device when sufficient memory space is notavailable to download and install the update to the VCS softwareprofile.
 34. The vehicle computer system configured to communicate witha mobile device of claim 31, wherein the message from the wirelesstransceiver includes information regarding a manufacturer of the mobiledevice or an operating system of the mobile device.
 35. A method ofcommunicating with a mobile device (MD), comprising: receiving a messagefrom the mobile device (MD) located in a vehicle indicating a version ofa MD software stack; determining if a vehicle software stack requires anupdate in response to the version of the MD software stack; downloadingand installing the update from an off-board server; providing an errorlog of software issues to the server; communicating with the MDutilizing the update.
 36. The method of communicating with a mobiledevice (MD) of claim 35, wherein the method includes outputting an errormessage on a display of a vehicle computer system (VCS).
 37. The methodof communicating with a mobile device (MD) of claim 35, wherein theerror message indicates software issues of the vehicle software stack.38. The method of communicating with a mobile device (MD) of claim 35,wherein the error message indicates that memory space is unavailable onthe VCS.
 39. The method of communicating with a mobile device (MD) ofclaim 35, the method further including the step of outputting anotification to insert an external memory device when sufficient memoryspace is not available to download and install the update to the vehiclesoftware stack.
 40. The method of communicating with a mobile device(MD) of claim 35, the method further including the step of outputting anotification that a network connection error is present when noconnection is available to download the update.